Universal RP는 결국 쓰게 되겠지만 아직 호환성이라던가 조금 다루기 난해한 부분이 있다. 그래서 기피한 것도 있고. 일단은 한번 알아보자

LWRP(Light Weight Render Pipline)로 시작해서 URP(Universal Render Pipline)로 2019.3버전에서 변경

실제 동일한 품질 설정에서 성능이 매우 향상될 수 있다고 한다. 그러니까 Draw call을 줄여서 Batches를 줄이고 그걸로 CPU와 GPU의 부하를 줄인다고 해야하나. 그런데 그렇게 때문에 더 화려한 효과를 많이 집어넣어 체감상으로는 훨씬 무거워진 느낌은 갖게 된다.

좀 더 기본으로 돌아가보자면 Render Pipeline이 뭔지부터 알아보자. 이 RP는 결국 랜더링을 어떻게 하냐이다. 씬의 오브젝트들을 가져가서 컬링, 렌더링, 포스트 프로세싱 등의 작업을 수행하고 그것을 스크린에 표기하는 역할을 하는 것이다. Built-in, URP, HDRP로 나누어서 작업할 수 있는데 처음부터 정하고 시작하는 것이 좋다. 연동성이라고 해야할지 호환성이라고 해야할지 아무튼 URP가 적용되는 에셋은 정해져있고 모든 에셋들을 URP로 적용하지 못한다면 많은 핑크색들을 보게 될 것이다.

built-in render pipeline(빌트인 렌더 파이프라인) 유니티에 기본으로 설정되어있는 디폴트(default) 렌더 파이프라인이다. 일반적인 목적의 렌더 파이프라인으로 커스텀 확장에 관해서 스크립터블 렌더 파이프라인(SRP)에 비해 제한적이다. 포워드 렌더링 패스(forward rendering path)와 디퍼드 렌더링 패스(defered rendering path)중 한가지를 선택할수있으며 커맨드 버퍼와 콜백으로 기능을 확장할수있다.

docs.unity3d.com/Manual/built-in-render-pipeline.html

SRP(scriptable render pipeline) 스크립터블 렌더링 파이프라인(SRP)을 사용하면 스크립트로 렌더링을 제어하고 커스터마이징할수있다. 개발자는 유니티가 프레임을 렌더링하는 방법을 c# 스크립트로 작성하여 프로젝트의 요구사항을 충족하기위해 기존의 파이프 라인을 수정하거나 재구성할수있다. 유니티는 2개의 빌트인 SRP를 제공한다(URP, HDRP)

learn.unity.com/tutorial/understanding-scriptable-render-pipelines-2019-3?language=en#5f670076edbc2a0020228d08

docs.unity3d.com/Manual/ScriptableRenderPipeline.html

URP(universal render pipeline) 유니티에 내장된 SRP로 LWRP의 업그레이드 버전이다(Unity 2019.3 버전부터 LWRP가 URP로 변경) URP는 뛰어난 성능 및 향상된 그래픽 품질을 제공하는 SRP로 기본 빌트인 렌더 파이프라인보다 유연하고 확장성이 좋으며 다양한 플래폼(모바일, 콘솔, PC, VR)에 최적화된 그래픽을 제공한다. 싱글 패스 포워드 렌더링, 셰이더 그래프, VFX 그래프를 지원한다(디퍼드 렌더러 지원 예정)

기존 Built-in Render Pipeline Flow Chart Unity Korea 유튜브를 보고 만든 플로우 차트다. 발표자료를 받을 수 있는것 같은데 어떻게 받는지 몰라서 그냥 그려봤다. 결국 가장 크게 바뀐것은 Render Pipeline이 엔진 밖에 있느냐 안에 있느냐 인것 같다. 네모칸 치는 것을 까먹었는데 게임 로직 밑에부분은 전부 엔진안에 있는 것이다.

URP Flow Chart 그런데 그 Render Pipeline을 엔진밖으로 끄집어내어 유저들이 Scriptable로 쓸수 있게 한것이 결국 SRP이고, 이를 사용하기 편리하게 유니티 자체에서 커스텀한것이 HDRP와 URP이다.

어쨋든 기본 개념은 개념이고 활용에 대한것은 예시 프로젝트를 써보고 실제로 사용해봐야 그 쓰임을 제대로 활용할 수 있지 않을까 싶다. 쓰기 편하다고 하는데 뭐 아직 잘 이해가 안된다.

아무튼 지금 현재 프로젝트에 적용을 하려고하는데 온통 분홍색이다. 새하얀 부분도 있다. Graphic API를 바꿔야한다는 내용이 있어 바꾸려고 하고있는데 하나 추가하거나 제거할때마다 1시간씩 걸린다. 돌아버리겠다.

근데 어쨋든 결국 Graphic API 와 ColorSpace를 OpenGL2, Gamma로 바꾸니까 어떻게든 해결이 되긴했는데.. 느리다. 많이 느리다. 컴퓨터 문제인가 해서 빌드한번 해보려고 하는데 빌드가 안된다.

이렇게 저렇게 하다보니 빌드가 됬는데 볼류메트릭 포그가 다 사라졌다. 개별로다. 추후 업데이트하겠다.

사실상 '경량화'는 메인 피쳐가 아닌 옵션이 되었고, 특수한 상황에서 Built-in 렌더러보다 좋은 성능을 보여주니 결국 필요에 따라 채택할 수 있는 선택지가 되었습니다. 이 일부 '특수한' 상황에 중점을 두어 기존 프로젝트를 업그레이드 해 퍼포먼스 이점을 노릴 수 없을까 고민하시는 분들이 종종 계시는데요, 사실 이미 많은 부분 개발이 완료되었거나 라이브 서비스 중인 프로젝트를 포팅하는 것은 그렇게 간단한 일이 아닐 수도 있습니다.

예를 들면, 외곽선(Outline) 효과나 카메라 스태킹, 데칼 렌더링을 위한 추가 패스, 포스트 프로세싱 외 특별한 효과를 위한 Image Effect 등 원하는 연출을 위해 다양한 방법으로 비주얼을 구현하셨을 겁니다. 위 효과들은 여느 게임에서나 쉽게 사용하는 이펙트들의 일부이며 구현 방법에 따라 부분적으로 URP로 전환이 어려울 수 있습니다.

유니버설 렌더 파이프라인에서는 기본적으로 포워드 렌더러(Forward Renderer)를 사용하는데요, 이는 여러 개의 라이트들을 하나의 패스에서 그려 라이트 당 추가 드로우 콜을 필요로 하지 않습니다. 다시 말해서, Built-In 포워드 렌더러는 여러 개의 라이트를 여러 패스로 그리지만 URP의 포워드 렌더러는 싱글 패스로 그리게 됩니다. 이는 비약적으로 렌더링에 걸리는 밀리초(ms)를 단축시켜 프레임의 상승을 도모할 수 있는 주요한 기능 중 하나입니다.

그러나 아직까지 디퍼드 렌더러에 대한 구현이 되어있지 않기 때문에 디퍼드로 그려야 하는 방식의 데칼, 아웃라인 기능들은 포워드에서 대안으로 사용할 수 있는 방식으로 재 구현해야 합니다. 만약 직접 구현하여 사용하고 있었다면 URP의 제한된 환경에도 Compatible 한 지 미리 확인해보아야 하며, 제네릭 한 포팅 과정이 복잡해지는 경우 성공적으로 포팅할 수 있을지도 고려해야 합니다. 에셋 구매해서 사용하는 경우 역시 URP에서 기능을 완전히 지원하는지 미리 확인해보아야 합니다.

카메라 스태킹을 지원한지도 오래되지 않았습니다. 일부 낮은 버전의 유니버설 렌더 파이프라인에서는 1개의 카메라만을 허용하고 있어, URP 7.2.1 이상 버전을 사용해야만 합니다. 1개의 메인 카메라와 그 위에 여러 개의 오버레이 카메라로 구성되는 방식을 취하고 있습니다. 이런 식으로 여러 카메라를 사용하는 경우 퍼포먼스상 불이익을 볼 수 있다는 것도 고려해야 합니다.

프로젝트 업그레이드 전 확인 사항 1. 직접 작성하여 사용중인 커스텀 셰이더가 있는지 확인 프로젝트 뷰에서 t:Shader 를 이용해 프로젝트에 포함된 모든 셰이더를 검색합니다.

셰이더가 있다면, 작성한 팀원이 아직 있는지 URP를 위한 셰이더 그래프 또는 hlsl로 포팅이 가능한지 확인합니다.

URP 포워드 렌더러 방식으로 구현 가능한지 검증합니다.

에셋스토어 페이지나 개발자에게 이메일로 확인할 수 있습니다. 가끔 따로 출시하여 추가 비용을 지불해야 하는 경우도 있습니다. 만약 지원 계획이 없다면 유니버설 렌더 파이프라인에서 지원되는 대체 에셋을 찾거나 포팅이 가능한지 확인합니다.

마치며 왜 유니버설 렌더 파이프라인으로 프로젝트를 진행하고 싶으신가요?

명확한 타깃 피쳐가 있어야 합니다.

어떤 효과를 보기 위해 빌트인 대신 URP를 선택하는지에 대한 근거가 명확해야 하며, 기능 구현에 대한 시간 투자와 인력 할당이 필수적입니다. 단순히 '새로 나온 기능이고 다른 프로젝트에서 종종 채택한다'거나 '싱글패스니까 항상 빠르겠지' 같은 안일한 접근으로는 열심히 작업하다 말고 도로 Built-in으로 유턴하는 경우가 생길지도 모릅니다. 유니버설 렌더 파이프라인은 Built-in 렌더러보다 빨라질 여지가 존재할 뿐 모든 경우에 대해 유리하지 않음을 인지해야 합니다.